Add CS2Tracker Extension - #213
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new Millennium plugin to the plugin database as a git submodule: CS2Tracker Extension, which injects CS2Tracker profile links into Steam community profile pages and friends-related lists.
Changes:
- Register
plugins/cs2tracker-extensionas a new git submodule pointing tohttps://github.com/MuhammedResulBilkil/cs2tracker-extension. - Pin the submodule to commit
9be073a7cdfaf91a3ad52ba1db86e8c0c1b4d492(tagv1.0.0).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
.gitmodules |
Adds the cs2tracker-extension submodule entry (path + upstream URL). |
plugins/cs2tracker-extension |
Adds the submodule gitlink pinned to the referenced upstream commit. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| [submodule "plugins/cs2tracker-extension"] | ||
| path = plugins/cs2tracker-extension | ||
| url = https://github.com/MuhammedResulBilkil/cs2tracker-extension |
There was a problem hiding this comment.
Fair point, and I'd rather answer it than leave it sitting.
The principle is right: master is a mutable ref, so the images the store renders after a merge aren't necessarily the images anyone reviewed. Pinning would fix that, and I've checked that it's a clean swap — all the referenced assets already resolve at the v1.0.0 tag, so it's a two-line change to plugin.json and a submodule bump here, nothing has to move.
What makes it awkward rather than automatic is the release pipeline. Releases here are cut by semantic-release, which decides the version number at release time and writes it into plugin.json itself. So a URL naming v1.0.1 has to be committed before the tooling has decided the release is v1.0.1, which means hand-holding a value the pipeline otherwise owns, on every release, forever, or the images silently keep pointing at the previous tag.
So: I'd rather do this properly at the next release, where I can wire the asset URLs into the same substitution semantic-release already performs on the version field, than bolt a hardcoded tag on now and quietly create a step that gets forgotten. If a maintainer would prefer it pinned before merge, say so and I'll cut a 1.0.1 for it — I just don't think a bot-flagged nit is worth a release on its own, and I'd rather ask than assume.
Worth noting for whoever picks this up: no other plugin currently in the database sets thumbnail or splash_image at all, so there's no house convention here either way. If the project does want pinned asset refs as a rule, that's a template or docs change rather than something to settle in one submission's thread, and I'm happy to be the first to follow it.
There was a problem hiding this comment.
Done — this is fixed rather than deferred. Thanks for the flag; it was a fair one.
The submodule now points at f5e67bf (v1.0.1), whose plugin.json reads:
"thumbnail": ".../cs2tracker-extension/v1.0.1/assets/thumbnail.png",
"splash_image": ".../cs2tracker-extension/v1.0.1/assets/splash.png"I said earlier I'd rather not hardcode a tag, because that fights semantic-release — it owns the version field — and adds a release step to forget. That objection turned out to be answerable rather than blocking: the rewrite now happens inside the prepare step that already syncs the version, so the tag in these URLs is derived from the release being cut, not typed by hand. @semantic-release/git commits plugin.json during prepare and semantic-release tags that commit, so the tag the URLs name is the tag they're committed under, and assets/ exists there. The apparent chicken-and-egg isn't one. Every future release re-pins itself.
The --check mode CI already runs gained the matching assertion, so a hand-edit back onto a branch ref now fails the build:
sync-version: plugin.json "thumbnail" is pinned to "master", not "v1.0.0"
$schema is deliberately left on Millennium's main so editor hints track the schema as it changes; the test suite asserts that exclusion so the rule can't later be widened to "every raw URL" and freeze it by accident.
v1.0.1 contains no functional change — it exists only to carry this. Both pinned URLs return 200 at the tag.
One note for whoever reviews, unchanged from before: no other plugin in the database sets thumbnail or splash_image at all, so there's still no house convention here. If the project wants pinned asset refs as a rule, that's a template or docs change rather than something to settle per-submission — happy to have been the first to follow it either way.
Pins `thumbnail` and `splash_image` to the release tag instead of `master`, so the images the store renders are the images reviewed here rather than whatever the branch points at later.
CS2Tracker Extension
Adds a CS2Tracker button to Steam community profile pages and a small badge to each row of the friends, pending-invite and recently-played-with lists. Clicking through opens
cs2tracker.gg/stats/{steamid64}for that player.Each badge and button reads its own player's Steam ID from the page it sits on, so a friend-row badge opens that friend's stats rather than the profile owner's. Three toggles in the settings panel control the profile button, the friend-list badges, and whether links open in Steam's browser or the system one.
Repository: https://github.com/MuhammedResulBilkil/cs2tracker-extension
Pinned at
f5e67bf, which is thev1.0.1release.v1.0.1exists only to answer the review comment below:thumbnailandsplash_imagenow point at the release tag rather thanmaster, so the images the store renders are the images reviewed here. The rewrite happens insemantic-release's prepare step, so every future release re-pins itself and there is no manual step to forget. No functional change to the plugin.How it differs from the plugins already on the store
leetify-extensionandcsstats-extensionlink out to Leetify and CSStats respectively; this one links to CS2Tracker, a different site. The profile button is deliberately styled to match the CSStats button's height, ground colour and wordmark treatment so that the three sit together as a row rather than competing visually — the screenshot above shows all three installed side by side.The friend-list badges are the part I haven't seen elsewhere: a per-row link on the friends, pending-invite and recently-played-with lists, each resolving that row's own account.
There is also #209 (Profile Button Config) open in this queue, which lets a user define arbitrary profile buttons from a URL template. I don't think the two make each other redundant, and I'd rather say why than leave a reviewer to wonder: PBC is a general tool for profile pages, configured by the user; this is a zero-configuration plugin for one site that also covers the friends lists, which a profile-page button cannot reach. Someone who wants a button for an arbitrary site is better served by PBC. If the maintainers see it differently I'd genuinely rather hear it now than after a merge.
Task Checklist
Developer
Plugin Functionality
Backend Configuration
"backendType": "lua"inplugin.json. It requireslogger,millenniumandjson, all of which Millennium preloads, and nothing else.main.lua.Community Contribution
Both were read against their pinned commit, then installed and run on Steam Stable with Millennium:
Testing Instructions
Install, restart Steam, enable under Millennium → Plugins, then:
/id/{vanity}profile as well. The Steam ID isn't in that URL, so this exercises a different resolution path.<style>element.Network behaviour, if you want to check it: the plugin makes exactly one request of its own, to
steamcommunity.comfor the current page's?xml=1view, and only when the profile's Steam ID isn't already available from the URL or the page's own globals. Everything else is a link the user clicks.